home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 988 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.7 KB

  1. Path: fido.asd.sgi.com!austern
  2. From: gregor@netcom.com (Greg Colvin)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: sample auto_ptr template
  5. Date: 06 Apr 1996 11:33:51 PST
  6. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <gregorDpFBCt.A5@netcom.com>
  9. References: <009A04DA6A831C40.49800EAC@ittpub.nl> <4jucle$i41@bmtlh10.bnr.ca>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: Sat, 6 Apr 1996 04:34:05 GMT
  12. Apparently-To: comp-std-c++@uunet.uu.net
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMWbHIEy4NqrwXLNJAQEDbQH9HBetsC2nmndl/JM9MT7gF0JG3tvuiNWO
  15.     M0HDnFP5t5k6xNz3xKX9LXYMk+GTPwY7bsd6dMngLlc5aamZqtKbGw==
  16.     =nw7g
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. In article <4jucle$i41@bmtlh10.bnr.ca> "john (j.d.) hickin" <hickin@bnr.ca> writes:
  20. ...
  21. >The January DWP continues to say that auto_ptr provides strict ownership
  22. >semantics [20.4.5  Template class auto_ptr]:
  23. >
  24. >2 The auto_ptr provides a semantics of strict ownership.  An object  may
  25. >  be  safely  pointed  to  by  only one auto_ptr, so copying an auto_ptr
  26. >  copies the pointer and transfers ownership to the destination.
  27. >
  28. >The implementation you have quoted does not contradict the above statement.
  29. >The January version of auto_ptr had the owner's stored pointer set to 0 so
  30. >that dereferencing under such conditions was not allowed:
  31. >
  32. >X& operator*() const;
  33. >
  34. >  Requires:
  35. >    get() != 0
  36. >  Returns:
  37. >    *get()
  38. >
  39. >A simple amendment to the DWP, perhaps already in the works, is all we require:
  40. >
  41. To my knowledge this is not "already in the works".
  42. >
  43. >X& operator*() const;
  44. >
  45. >  Requires:
  46. >    owner == true
  47. >  Returns:
  48. >    *get()
  49. >
  50. >With change, dereferencing will, as before, be undefined when ownership is 
  51. >not held.
  52.  
  53. Please remember that auto_ptr is designed to make sure that pointers are 
  54. deleted when exceptions are thrown, not to be sure that already deleted
  55. pointers are not misused.  The semantics of auto_ptr are intentionally
  56. "as close as possible" to ordinary pointers: if you use a pointer that is
  57. already deleted the behaviour is undefined, and the same for auto_ptr; if you
  58. use a pointer that is owned by another object (i.e. will be deleted by that
  59. objects destructor) the behaviour is well defined as long as the pointer
  60. remains valid, and the same for auto_ptr; you cannot tell at runtime whether
  61. a pointer is valid, and the same for auto_ptr.
  62.  
  63. What you can do is design your code so that you know who owns each object when.
  64. The auto_ptr template can help you implement such designs safely.  If you
  65. cannot design your code to work with auto_ptr you probably need garbage
  66. collection of some form.
  67.  
  68. I do not forsee any fundamental changes in the auto_ptr design: its too late
  69. and has taken too much work to get it where it is today.  The important issues
  70. are whether it is completely and correctly specified, and whether any
  71. necessary features are missing.  In particular:
  72.    * Should auto_ptr have an operator-> ?  A proposal to add one was nearly 
  73.      accepted at Santa Cruz, but was withdrawn when the prerequisite extension
  74.      failed.
  75.    * Should auto_ptr have an operator== ?
  76.    * Should any of the auto_ptr functions have exception specifications?
  77.    * Many of the requirements can be diagnosed at compile-time but are only
  78.      specified to produce undefined behavior at run-time.  Should we tighten the
  79.      specification?  If so, how?
  80.  
  81. Greg Colvin
  82. gregor@netcom.com
  83. ---
  84. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  85.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  86.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  87.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  88.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  89. ]
  90.